General Structure & Best Practices

 

General sequence of the transaction elements should be:

  1. EffectiveDate

  2. Allocations (if applicable)

  3. Suspense

  4. Withholding

  5. Valuation (if applicable)

  6. Fields

  7. Events

  8. Validation

  9. Math  

  10. Within the <Math> section, any MathVariable constants should come first.

  11. Assignments (if applicable)

  12. ActivityAmounts (if applicable)

  13. MultiFields

  14. Spawns  

 

Syntax standards according to the General Structure

  1. EffectiveDate

    1. The EffectiveDate element should be the first tag in a transaction.

    2. The EffectiveDate of spawned transactions, when that spawned activity is only ever SYSTEM generated, should be Disabled.  
       

  2. Allocations

    1. Allocation order of elements should be:

  3. Suspense

    1. Use the OVERRIDABLE attribute to allow users to bypass suspense requirements.
       

  4. Withholding

    1. When withholding is needed, use the <Withholding> </Withholding> tags instead of creating fields for withholding.
       

  5. Valuation

    1. Do not include the <Valuation> tag in a transaction, if valuation is not necessary.
       

  6. Fields

    1. The order of field tags is:

    1. The <DefaultValue> tag or <Calculated> tag may not be present at the same time.  Use one or the other.

    2. If a field is hidden, do not include a <Disabled> tag.

    3. If a field is not hidden, do not include <Hidden> tag.

    4. If a field is not disabled, do not include <Disabled> tag.

    5. Hidden fields that are independent of other fields should be placed at the end of the <Fields> section.  

    6. Suggestions for field names are listed below. This applies to MathVariable names as well.

    7. Do not use spaces or underscores.  

Example: DateOfBirth not Date_of_Birth.

    1. Do not abbreviate unless the resulting word is extremely long.  In that case, abbreviate but retain the meaning of word.  

Examples:  PolicyAnniversary not PolAnniv. NextMonRemainIssueChg for NextMonthaversaryRemainingIssueCharge.

    1. Add abbreviated words to the Data Dictionary so that the meaning remains clear.

    2. Field name and display value should be the same if possible.

Example: <Name>IssueDate</Name>, <Display>Issue Date</Display> not <Display>Date of Issue</Display>.

    1. Filler fields should be blank for the display and DataType.

    2. Combo boxes and radio buttons:

  1. Math

  1. When defining the TYPE for a MathVariable use:

  2. When defining the constant of Checked or UnChecked, the values should always be either CHECKED or UNCHECKED in all capital letters, respectively.

  3. Use the PlanScreen business rule any time the amount or piece of information is constant for the plan you are configuring. This will allow rules to all use this value in a constant fashion.  If the information should change, then only one change must be made. This eliminates the need to update every transaction or rule that hard coded constant plan values.

  4. Use PlanFields any time a particular fact, amount, threshold value, etc., is tied to a product (plan), and is used in a constant fashion across multiple transactions and/or calculations.  It should be defined in PlanFields rather than defined repeatedly in a transaction or calcGeneral XML.  

  5. XPATHs should always use the fully qualified path.  

Example: /Valuation/Policy/FundList/Fund[FundGUID='$$$LoanCreditFundGUID1$$$']/CashValue not //FundList/Fund[FundGUID=’$$$LoanCreditFundGUID1$$$’]/CashValue

  1. When using TYPE=”FUNCTION”, do not use double quotes around the fields.

  2. Quotes aren’t needed if a MathIF is used when comparing numbers.

Example:  ActiveSegmentCode=01

  1. The use of Blank is not needed when blank is a previously defined field.  Instead use two single quotes.

  2. Use Data Dictionary defined field names for consistency across products.

  3. Don’t define MathVariables that aren’t used anywhere.

  4. Use Valuation:Policy to retrieve values from valuation when possible.

  5. Capitalize the words AND and OR when writing SQL.  Use sentence case And and Or when configuring anything other then SQL statements.

  6. A MathVariable should define its VARIABLENAME and TYPE attributes prior to any other attribute.

Example: <MathVariable VARIABLENAME=”Example” TYPE=”SQL” DEFAULT =”01”>

  1. Only use ROUND when there is a reason.

  2. Consolidate logic into a single MathVariable where appropriate.

Example: Where an intermediate calculation value is not needed &endash; don’t break the calculation into many steps.

  1. Suggestions for when to use MathIF versus TYPE=”IIF”:  

 

  1. Multifields

  1. Multifields must be treated separately from fields in the regular part of the transaction.  You can’t cross reference fields.

  2. Any Multifield field validation, other than verifying whether a field was left blank, must be done in the math of the transaction.
     

  1. Spawns

  1. Pass spawn fields in the same sequence as configured in the transaction that is being spawned.

  2. Any GUID fields passed as spawn fields should be disabled in the spawned transaction.

  3. Spawned transactions should use SPAWNCODE=”01” when the spawned transaction is effective on the same day as the spawning transaction.  

  4. See AsCode for other spawn code values.

  5. DataTypes in spawn fields must match DataTypes in receiving fields.